昨天終於把三個Test Case 寫完了，今天就是開始動手的時候了。首先我們demo static suites 所有的test case 選擇起來，我們來指定tester。首先我們先選在我們想要assign的test suite上，然後右鍵按下assign tester to to run all tests。
另外一提，前面有講到Configuration 的地方，如果你要進行不同作業系統，或是不同瀏覽器的測試設定，可以在這裡按下Assign Configuration 來進行設定，我這次就只有預設在windows 10平台上進行。
這時候，我們指定兩位測試者。測試邀請信件預設是英文的標題，如果你怕你的測試者以為是社交工程的信件，一定一定要寫一些讓他看得懂的字，不然就到垃圾桶了。
那因為剛剛是指定兩個測試者，原本三個Test Case 就變成了兩倍六個Test Point(測試點)，然後測試者就各有不同。
然後呢，測試者就會收到通知郵件，讓我們知道，我們被指定測試。
到這裡我們先停一下，有點疑問。因為前面20天我們的工作項目，不會離開feature、user story或是task，要如果是議題就會是issue。測試工作應該也算是一個task吧？我們去board找看看。
你會發現，筆者在寫這篇文章的那一天，剛剛已經assign了兩位測試者，居然在這裡並不是一個Task，因此只有看到山姆大叔可愛的小孩的大頭，有三個tast case以及一個share parameter，SC剛剛也被指定了，這裡卻甚麼都找不到？
我們再回去Test Plan去尋找一下，卻也只有Test suite可看到剛剛的test case 變成兩份....但山姆大叔的帳號，也可以幫SC按下測試完成，這到底....好吧，千錯萬錯一定是山姆大叔學藝不精，所以我真的有點不能理解設計的邏輯為何。
那在網路爬文中爬到了一篇文章。
這篇文章講了幾個重點：
測試案例受託人實際上與測試案例測試人員不同，但是您必須深入挖掘才能找到任何形式的文檔，這些文檔僅存在於 Microsoft FAQ 頁面中 (而且這篇文章居然是2012的!!!!!!!)。
當使用者被指派到測試案例時，使用者會收到電子郵件通知。當使用者作為測試人員被指派到測試執行時，無論在任何地方，與使用者的通訊都是零。
測試執行不被視為工作項目（這是一個非常奇怪的概念，但聽起來像是微軟的技術決策而不是功能決策）。
Microsoft 決定更重要的是通知測試案例作者他們需要調整測試案例，而不是通知測試人員他們在測試計劃中具有出色的測試執行。
經過同事認真研究了一個月，再看到這篇文章，實在不能夠不認可上述的一些觀點。因為在其他所有的任務中，開發者、需求者或是維運人員，所有的項目都跟work item有關係，而test plan->test suite->test case 甚至到share steps 或是 share parameters，全部都可以在work item中找到(有些隱藏起來無法直接找到，但是還是可以透過方法找到）。
但是今天一個測試人員被指定了測試工作後，他卻只有一封信件通知，然後這個訊息就斷掉了，除非這位測試者熱愛他的工作一直進去看test plan，不然萬一漏信或是被信件淹沒，他就無法安排他的工作了，非常奇怪。
但可能這功能貴，買的人不多，所以跟進回覆的人也不多，因此2020到現在2023年9月，看起來這個問題並沒有被修正，而是沉默了。
另外我也去翻了azure devops service 的product road map，跟test plan 有關係的都跟上面提的完全沒有關係，反而在提升pipeline ux或是code coverage result 之類的，所以看起來微軟並沒有認為這是一個問題。
好吧，我們也只能試著去摸索看看到底怎麼繼續完成我們的任務了，明天就會講到在這幾天的Test Plan 中，我們認為最棒的地方了。
測試的人與開發的人，看起來在一起，又好像分開。
iThome鐵人賽
看影片追技術